Content delivery network map generation using passive measurement data

ABSTRACT

A routing method operative in a content delivery network (CDN) where the CDN includes a request routing mechanism for routing clients to subsets of edge servers within the CDN. According to the routing method, TCP connection data statistics are collected are edge servers located within a CDN region. The TCP connection data statistics are collected as connections are established between requesting clients and the CDN region and requests are serviced by those edge servers. Periodically, e.g., daily, the connection data statistics are provdied from the edge servers in a region back to the request routing mechanism. The TCP connection data statistics are then used by the request routing mechanism in subsequent routing decisions and, in particular, in the map generation processes. Thus, for example, the TCP connection data may be used to determine whether a given quality of service is being obtained by routing requesting clients to the CDN region. If not, the request routing mechanism generates a map that directs requesting clients away from the CDN region for a given time period or until the quality of service improves.

[0001] This application is based on and claims priority from ProvisionalApplication Serial No. 60/296,375, filed Jun. 6, 2001.

BACKGROUND OF THE INVENTION

[0002] 1. Technical Field

[0003] The present invention relates generally to high-performance,fault-tolerant HTTP, streaming media and applications delivery in acontent delivery network (CDN).

[0004] 2. Description of the Related Art

[0005] It is well-known to deliver HTTP and streaming media using acontent delivery network (CDN). A CDN is a network of geographicallydistributed content delivery nodes that are arranged for efficientdelivery of digital content (e.g., Web content, streaming media andapplications) on behalf of third party content providers. A request froma requesting end user for given content is directed to a “best” replica,where “best” usually means that the item is served to the client quicklycompared to the time it would take to fetch it from the content providerorigin server. An entity that provides a CDN is sometimes referred to asa content delivery network service provider or CDNSP.

[0006] Typically, a CDN is implemented as a combination of a contentdelivery infrastructure, a request-routing mechanism, and a distributioninfrastructure. The content delivery infrastructure usually comprises aset of “surrogate” origin servers that are located at strategiclocations (e.g., Internet network access points, Internet Points ofPresence, and the like) for delivering copies of content to requestingend users. The request-routing mechanism allocates servers in thecontent delivery infrastructure to requesting clients in a way that, forweb content delivery, minimizes a given client's response time and, forstreaming media delivery, provides for the highest quality. Thedistribution infrastructure consists of on-demand or push-basedmechanisms that move content from the origin server to the surrogates.An effective CDN serves frequently-accessed content from a surrogatethat is optimal for a given requesting client. In a typical CDN, asingle service provider operates the request-routers, the surrogates,and the content distributors. In addition, that service providerestablishes business relationships with content publishers and acts onbehalf of their origin server sites to provide a distributed deliverysystem. A commercial CDN service that provides web content and mediastreaming is provided by Akamai Technologies, Inc. of Cambridge, Mass.

[0007] A typical CDN edge server includes commodity hardware, anoperating system such as Linux, a TCP/IP connection manager, a cache,and one or more applications that provide various functions such ascache management, logging, and other control routines that facilitatethe content delivery techniques implemented by the CDNSP at the server.In an illustrative case, the operating system kernel is Linux-based andtracks and provides access to per session and aggregate TCP/IPinformation, such as per-system number of packets, bytes sent andreceived, number of retransmits, and the like. The TCP connectioninformation that is available from monitoring the operating systemkernel has not been fully mined for its potential value, especially toCDN service providers. TCP stream state data, however, generatesimplicit information about the state of the network. Thus, for example,packet retransmissions can indicate congestion within the network. Anestimated round-trip-time (RTT) derived from TCP connection informationindicates latency to a remote host. Early FIN message receipt canindicate a dropped connection. A lower window size than usual canindicate instability in topological path. Each session's overall andsmaller time-scale throughput is one of the best measures of actualend-user performance.

[0008] It would be desirable to be able to use edge server CDNstatistics in other CDN control processes.

BRIEF SUMMARY OF THE INVENTION

[0009] According to the invention, TCP connection information resultingfrom prior CDN mapping decisions to a given edge server region (or to agiven edge server therein) is logged, aggregated, and then used toimprove subsequent routing of client requests to servers in a contentdelivery network.

[0010] More generally, it is an object of the invention to use passivemeasurement data to facilitate the generation or evaluation ofclient-to-server request routing maps in a content delivery network.Passive measurement data is logged at CDN edge server machines,preferably on a per-connection basis or a per HTTP connection basis.

[0011] It is another more specific object of the invention to collectTCP connection information from CDN edge servers to allow networkperformance to be correlated with particular hosts or address blocks,allowing for improved maps to be generated during the CDN map generationprocess.

[0012] According to the present invention, TCP statistics data fromremote machines is logged and delivered back to a central location andused by a CDN to generate request routing maps, such as an IP block toCDN region map. This enables the CDN map to be modified as a function ofpassive measurement data that reflects how well the CDN request routingmechanism actually mapped prior web requests.

[0013] The present invention generally describes a routing methodoperative in a content delivery network having a request routingmechanism for routing clients to edge servers. At a given edge serverlocated within a CDN region, data associated with one or moreconnections that have been established between requesting clients andthe CDN region is collected. That data is then provided back to therequest routing mechanism, where it is used is a subsequent routingdecision. Preferably the data is per HTTP connection data collectionfrom a configurable percentage of client requests that are serviced bythe given edge server. This TCP connection data preferably is aggregatedwith similar data from other edge servers in the CDN region before beingpassed back to the CDN request routing mechanism. This enables therequest routing mechanism to make new maps based on an accurate view asto how well given connections are being serviced within the CDN region.

[0014] In a more detailed, yet illustrative embodiment, a routing methodis operative in a content delivery network (CDN) where the CDN includesa request routing mechanism for routing clients to subsets of edgeservers within the CDN. According to the routing method, TCP connectiondata statistics are collected are edge servers located within a CDNregion comprising a subset of edge servers. The TCP connection datastatistics are collected as connections are established betweenrequesting clients and the CDN region and requests are serviced by thoseedge servers. Either in real-time or delayed (e.g., hourly or daily),the detailed and/or summarized connection data statistics are providedfrom the edge servers in a region back to the request routing mechanism.The TCP connection data statistics are then used by the request routingmechanism in subsequent routing decisions and, in particular, in the mapgeneration processes. Thus, for example, the TCP connection data may beused to determine whether a given quality of service is being obtainedby routing requesting clients to the CDN region. If not, the requestrouting mechanism generates a map that directs requesting clients awayfrom the CDN region for a given time period or until the quality ofservice improves.

[0015] The foregoing has outlined some of the more pertinent objects andfeatures of the present invention. These objects should be construed tobe merely illustrative of some of the more prominent features andapplications of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

[0016] For a more complete understanding of the present invention andthe advantages thereof, reference should be made to the followingDetailed Description taken in connection with the accompanying drawings,in which:

[0017]FIG. 1 is a diagram of a known content delivery network in whichthe present invention may be implemented;

[0018]FIG. 2 is a simplified diagram of a two level request routingmechanism used in the content delivery network of FIG. 1;

[0019]FIG. 3 is a simplified diagram of a typical CDN edge server thathas been modified to include the TCP statistics monitoring processaccording to the present invention; and

[0020]FIG. 4 is an simplified diagram of how TCP data is logged,aggregated and then delivered to a CDN request routing mechanism in anillustrative embodiment of the present invention.

DESCRIPTION OF THE PREFERRED EMBODIMENT

[0021] As seen in FIG. 1, an Internet content delivery infrastructureusually comprises a set of “surrogate” origin servers 102 that arelocated at strategic locations (e.g., Internet network access points,and the like) for delivering copies of content to requesting end users119. A surrogate origin server is defined, for example, in IETF InternetDraft titled “Requirements for Surrogates in the HTTP” dated Aug. 9,2000, which is incorporated herein by reference. The request-routingmechanism 104 allocates servers 102 in the content deliveryinfrastructure to requesting clients in a way that, for web contentdelivery, minimizes a given client's response time and, for streamingmedia delivery, provides for the highest quality. The distributioninfrastructure consists of on-demand or push-based mechanisms that movecontent from the origin server to the surrogates. A CDN service provider(CDNSP) may organize sets of surrogate origin servers as a “region.” Inthis type of arrangement, a CDN region 106 typically comprises a set ofone or more content servers that share a common backend, e.g., a LAN,and that are located at or near an Internet access point. Thus, forexample, a typical CDN region may be co-located within an InternetService Provider (ISP) Point of Presence (PoP) 108. A representative CDNcontent server is a Pentium-based caching appliance running an operatingsystem (e.g., Linux, Windows NT, Windows 2000) and having suitable RAMand disk storage for CDN applications and content delivery networkcontent (e.g., HTTP content, streaming media and applications). Suchcontent servers are sometimes referred to as “edge” servers as they arelocated at or near the so-called outer reach or “edges” of the Internet.The CDN typically also includes network agents 109 that monitor thenetwork as well as the server loads. These network agents are typicallyco-located at third party data centers or other locations. Map makersoftware 107 receives data generated from the network agents andperiodically creates maps that dynamically associate IP addresses (e.g.,the IP addresses of client-side local name servers) with the CDNregions.

[0022] In one service offering, available from Akamai Technologies, Inc.of Cambridge, Mass., content is marked for delivery from the CDN using acontent migrator or rewrite tool 106 operated, for example, at aparticipating content provider server. Tool 106 rewrites embedded objectURLs to point to the CDNSP domain. A request for CDN-enabled content isresolved through a CDNSP-managed DNS to identify a “best” region, andthen to identify an edge server within the region that is not overloadedand that is likely to host the requested content. An illustrativerequest routing technique is described in U.S. Pat. No. 6,108,703, whichis incorporated by reference. Instead of using content provider-sidemigration (e.g., using the tool 106), a participating content providermay simply direct the CDNSP to serve an entire domain (or subdomain) bya DNS directive (e.g., a CNAME). In such case, the CDNSP may provideobject-specific metadata to the CDN content servers to determine how theCDN content servers will handle a request for an object being served bythe CDN. Metadata, as used herein, refers to the set of control optionsand parameters for an object (e.g., coherence information, origin serveridentity information, load balancing information, customer code, othercontrol codes, etc.), and such information may be provided to the CDNcontent servers via a configuration file, in HTTP headers, or in otherways. An object URL that is served from the CDN in this manner need notbe modified by the content provider. When a request for the object ismade, for example, by having an end user navigate to a site and selectthe URL, a customer's DNS system directs the name query (for a domain inthe URL) to the CDNSP DNS request routing mechanism. Once an edge serveris identified, the browser passes the object request to the server,which applies the metadata supplied from a configuration file or HTTPresponse headers to determine how the object will be handled.

[0023] The CDNSP may operate a metadata transmission system 116comprising a set of one or more servers to enable metadata to beprovided to the CDNSP content servers. The system 116 may comprise atleast one control server 118, and one or more staging servers 120 a-n,each of which is typically an HTTP server (e.g., Apache). Metadata isprovided to the control server 118 by the CDNSP or the content provider(e.g., using a secure extranet application) and periodically deliveredto the staging servers 120 a-n. The staging servers deliver the metadatato the CDN content servers as necessary.

[0024] As illustrated in FIG. 2, a dynamic DNS system 200 such asdescribed generally above directs each user web request 202 to theoptimal server 204 for content delivery. In one approach, a “top level”map 206 directs a specific request to one of a given number of serverregions, while a “low level” map 208 further directs the request to agiven server within a region. Thus, for example, the top level map 206may associate each Internet IP address block with a CDN server regionthat can deliver content to clients in that block most quickly. Toprepare for generating this map, mapping agents (e.g., one per CDNserver region) may collect the following information: (a) IP blocks (alist of IP address blocks currently in use in the Internet), (b) load(per-IP block measurements of the amount of web load currently beinghandled by the CDN, (c) communication costs (e.g., a table listing themeasured communication cost for each {IP block, CDN server region} pair,and (d) capacity (e.g., an aggregate server and network capacity of eachCDN server region). A combination of different methods may be used toput together the list of IP blocks representing all of the leaf networks(e.g., endpoint LAN's on the global Internet): BGP peering, harvestinginformation from network registration databases (e.g., RIPE, APNIC andARIN), and random traceroutes into very large blocks (e.g., UUNET). Theload on the CDN generated by each IP block may be determined bygathering and aggregating measurements from the CDN content servers. Oneor more different communication costs may be used to determine the costof communication between an IP block and a CDN server region: networkhealth of server region (e.g., a binary metric indicating that theregion is up or down), ASPATH length between the block and the serverregion (e.g., as supplied by BGP), round trip time (RTT) between theregion's mapping agent and a given point in the IP block, packet lossrate between the region's mapping agent and the given point in the IPblock, geographic distance, and perhaps others. These metrics may becombined into a single cost metric for each IP block, server regionpair, with the priority, or weighting, of each individual metric set tobe proportional to its position on the list. Two types of capacitymeasurement may be made: total server capacity in each region andphysical network capacity in each region. The server capacity isdetermined, for example, from the number of servers currently up in aregion. Physical network capacity is determined, for example, withpacket pair measurements. Region capacity may be calculated as a givenfunction (e.g., the minimum) of these two measurements.

[0025] As noted above, the top level map 206 maps each IP block to anoptimal CDN server region. One technique for generating the top levelmap involves identifying a number of candidate regions for each IP block(e.g., based on the {IP block, server region} communication costs),generating a bipartite graph using all of the measured and collectednetwork information (e.g., with one side of the graph representing eachof the IP blocks and the other side representing CDN server regions),and then running a min-cost flow algorithm on the graph. Each IP blocknode is labeled with its measured load, which is treated as the “flow”coming from that node. Running the algorithm results in an optimalassignment of IP block load to server regions. This assignment is thetop level map, which is generated periodically and then delivered to thedynamic DNS request routing mechanism. The above map generation processis merely exemplary and is not meant to limit the present invention ofcourse.

[0026]FIG. 3 illustrates a typical machine configuration for a CDNcontent server. Typically, the content server 300 is a Pentium-basedcaching appliance running an operating system kernel 302 (e.g., based onLinux), a file system cache 304, CDN control software 306, TCPconnection manager 308, and disk storage 310. CDN control software 306,among other things, is useful to create an object cache 312 for popularobjects being served by the CDN. In operation, the content server 300receives end user requests for http content, determines whether therequested object is present in the hot object cache or the disk storage,serves the requested object (if it is present) via http, or itestablishes a connection to another content server or an origin serverto attempt to retrieve the requested object upon a cache miss. Accordingto the invention, the CDN software 306 also includes a logging routine,called TCPStats 314, which in an illustrative embodiment logs a recordfor every TCP connection made to/by the machine on which this softwareis running in addition to connections made to/by the CDN softwareprocess itself. Generalizing, the TCPStats process logs arbitrary piecesof information about a TCP connection.

[0027] In an illustrative embodiment as shown in FIG. 4, each edgeserver 400 in a region runs one or more monitoring processes 402, and aninstance of a query process 404. A monitoring process monitors thehealth of the local machine and the network to which it is connected;another monitoring process monitors the hits and bytes served by the CDNsoftware running on the machine. The TCP statistics monitoring ispreferably performed by one of these monitoring processes 402.Generally, the TCP statistics data is collected by that process and madeavailable to the local instance of the query process 404. Periodically,a central instance of the query process 406 running on an aggregatormachine 408 (typically somewhere else in the network) makes a request tothe local instance of the query process. There may be a hierarchy ofaggregators, depending on the size and scope of the network deployment.When requested, the query process collects tables of data from machinesin the same region (typically within a given data center) and relaysthem to the aggregator machine 408, which accumulates and stores thedata. According to the invention, the TCP statistics data is thensupplied to the CDN request routing mechanism 410 to facilitate futuremapping decisions. Data preferably is delivered between machines over asecure connection, which can be implemented with known software tools.

[0028] Generalizing, TCPStats data aggregated from the CDN contentservers is used in subsequent revisions to a given map, e.g., the IPblock to CDN region map. In particular, the TCPStats data provides anadditional refinement to the map making process to provide a map thatincludes passive measurement data about how a given number of individualrequests were previously routed by the CDN request routing mechanism.This feedback mechanism enables a more accurate map to be generated inthe future based, in part, on an after-the-fact evaluation of how wellearlier CDN mapping decisions routed prior requests, preferably on anaggregate basis, as evidenced by the actual TCP statistics logged at theCDN content servers within a given region. If, for example, thosestatistics illustrate that prior mapping decisions with respect to agiven region did not provide a sufficient quality of service, then themap making process can be modified appropriately.

[0029] As a specific example, assume that TCPStats data is aggregated ona per machine and per region basis. This data enables a given process tomonitor the health of the region itself, especially if the data is usedin conjunction with other historical data. The TCPStats data providesdetailed information about the quality of the connections to the variousmachines in the region. If that data establishes that connections to theregion (in general, or for a specific IP block mapped to the region) arereceiving a quality of service below a given threshold, the map makingalgorithm may then bias requests away from that region for a given timeperiod or until the connectivity data shows improvement. As anotherexample, assume that the map generation process identifies two (2)regions that appear equally good for handling a given request. In suchcase, the TCPStats data can be used as a tiebreaker. In addition, theTCPStats data may be used to provide an indication of how well themapping algorithm performed over a given time period (e.g., daily). Ofcourse, the above examples are merely exemplary and should not be takento limit the scope of the present invention, which should be broadlyconstrued to cover the use of the TCP Stats passive measurement data tofacilitate the generation or evaluation of client-to-server requestrouting maps in a content delivery network.

[0030] The TCP/IP protocol's fully-reliable transport model andintricate congestion control mechanisms allow a CDNSP to gather a greatdeal of useful information. The following is representative. Thus, on aper client x server x URL basis, the CDNSP can determine, for example:the number of bytes transmitted, the duration of connection (includingthe duration of each phase of the connection), loss seen in theconnection, latency between client and server as measured and used,variance in latency seen between the client and server, themaximum/average measurements of the size of the network connectionbetween the client and server, overall and instantaneous throughput,window size and the like. In an illustrative embodiment, TCP statisticsacross three (3) axes (client, server, and URL) are collected by theTCPStats process and is used to provide a profiling tool for everyconnection.

[0031] More specifically, TCP statistics entries may include one or moreof the following fields (familarity with the TCP/IP protocol isassumed):

[0032] Time initial SYN packet was received (sent): this is the time thefirst packet on the connection was received (if the connection came froma remote client) or sent (if a connection is being established to aremote server). The time is expressed in sec.msec, where sec is numberof seconds since a Unix epoch and msec is the number of millisecondssince the beginning of that second. All other times preferably areoffsets from this time.

[0033] Local IP address:port: the IP address of the machine that the CDNsoftware runs on, which is specified in the 4 byte dotted quad notation(w.x.y.z) followed by a colon (:) and the local IP port number.

[0034] Direction: a single character identifier that tells if theconnection was made local to remote machine (‘>’) or remote to localmachine (‘<’).

[0035] Remote IP address:port: IP address of the remote machine in 4byte format, a colon, and the remote IP port number.

[0036] Number of packets received.

[0037] Number of packets sent.

[0038] Number of duplicate packets sent (retransmits).

[0039] Total bytes sent.

[0040] Total bytes received.

[0041] Total duplicates bytes sent and received.

[0042] Max Smooth Round Trip Time (SRTT) during the connection (inmsec).

[0043] Min Smooth Round Trip Time during the connection.

[0044] Log of RTT estimates obtained and/or summary statistics.

[0045] Log of calculated SRTT values and/or summary statistics.

[0046] Time spent in each phase of the states associated with the TCPconnection:

[0047] From begin until ESTABLISHED: the elapsed time from the receiptof the initial SYN from the client (the second field in the log entry)until the ACK of the initial SYN-ACK is received by the CDN softwareprocess. In the case of a forward connection, this is the time from SYNsend until the SYN-ACK was received by the remote server. This and allother delta times below are expressed as msec, the number ofmilliseconds from the connection begin time (SYN time, as describedabove).

[0048] Time from begin until FIN_WAIT: The elapsed time between when theconnection began and when the connection got into the FIN_WAIT state(zero if not applicable).

[0049] Time from begin until FIN_WAIT1 state (zero if not applicable).

[0050] Time from begin until FIN_WAIT2 state (zero if not applicable).

[0051] Time from begin until CLOSING state (zero if not applicable).

[0052] Time from begin until the last ACK was received (zero if notapplicable).

[0053] Time from begin until WAIT state (zero if not applicable).

[0054] # Duplicate ACK's sent

[0055] Max window size (in bytes)

[0056] Number of Times the RTO timer expired

[0057] Delayed ACK count

[0058] Average window size

[0059] Average IP TTL observed

[0060] TCPStats data is generated by any convenient mechanism. The Linuxoperating system kernel provides some of this data directly. Inparticular, the kernel keeps track and provides access to aggregateinformation including per-system number of packets, bytes sent andreceived, and number of retransmits, among other things. To facilitateTCP statistics collection, the operating system kernel preferably ismodified to provide access to per-connection statistics. The modifiedcode keeps track of that information per-connection (in the kernel) andprovides an interface for an application to mark a connection asinteresting and to get its connection information when the connection iscomplete. Preferably, the application also implements per-HTTPconnection statistics. This requires marking a TCP connection with thebeginning and end points of an HTTP request. The kernel keeps track ofbytes sent/received for the duration of the request and providesstatistics to the application upon request. This allows a more accurateestimation of per-connection bandwidth than is possible withper-connection statistics because many TCP connections are allowed tostay open (in an HTTP persistent connection state) after the HTTPresponse has been sent, in the hopes another request will reuse theestablished connection. In contrast, just looking at bytes sent/totaltime is not as accurate a measure, as the per connection time willreduce the apparent bandwidth by a significant amount. In anillustrative embodiment, these statistics are provided by the kernel touser space preferably through a device file interface, which is astandard way for the kernel to communicate with an application. Thestatistics themselves preferably are kept in a circular memory buffer sothat the kernel does not run out of memory even if the loggingapplication lags behind. Preferably, the application is designed to readall available statistics out of the kernel at a configurable interval(e.g., once per second) and to write statistics into a log for aconfigurable fraction of all requests (e.g., 1%). This allows theapplication to obtain a statistical sample of all of traffic served fromthe machine. Preferably, the application marks when it is sending andreceiving data to get better bandwidth measurements. More informationabout the TCP/IP protocol and the Linux operating system kernel can beobtained from the following resources: Stevens, TCP/IP IllustratedVolume 1: The Protocols. Addison-Wesley, and Beck, et al., Linux KernelInternals, Second Edition. Addison-Wesley.

[0061] Other techniques for collecting the TCP statistics informationmay also be used. Thus, for example, the CDN edge server may beprovisioned with a tcpdump process and a filter to look at the TCPpacket headers and collect information from them (such asretransmission, and the like). This is a less invasive approach thanmodifying the kernel, but it does creates additional load onto theserver. In this embodiment, the filter needs to keep track of state suchas open connections and also needs to deduce retransmissions, and thelike, from the packets it sees going across the wire. Alternatively, theCDN server process can simply gather information about the TCP state ofopen sockets and log such data along with other connection data. Thepreferred approach, as described above, is instrument the kernel tostream TCP state information to a separate user-space process thatcollects it, processes it, and then feeds the data back to the requestrouting mechanism as appropriate.

[0062] Variants

[0063] In an alternate embodiment, the CDNSP can cause TCP statisticsdata to be generated for a given region (or to a particular prefix),irrespective of whether the region is suspected of being good orbad-performing. In this embodiment, the system generates a randommapping of a given request, which causes measurements to be made at therespective region so that performance of the region can be evaluated.This provides a network monitoring method.

[0064] The CDNSP may perform given filtering in an edge region toanalyze the TCP statistics and look for unusual performance issues on,for example, a per CIDR block, per prefix, per AS, or other basis. Theresults of such filtering may then be fed back to generate controlcommands to the request routing mechanism (e.g., “stop mapping Sprint(AS1239)”).

[0065] The CDNSP may also obtain TCP statistics from a customer originserver and use such information to find a best customer region.

[0066] Of course, one of ordinary skill in the art will also appreciatethat the techniques of monitoring connection data and using thatinformation to influence a routing decision as described herein may beextended beyond the use with CDN request routing mechanisms to generalIP traffic routing mechanisms.

Having described my invention, what I claim is as follows:
 1. A routingmethod operative in a content delivery network having a request routingmechanism for routing clients to edge servers, comprising: at a givenedge server located within a CDN region, collecting data associated withone or more connections that have been established between requestingclients and the CDN region; providing the data to the request routingmechanism; and using the data in a new routing decision.
 2. The routingmethod as described in claim 1 wherein the data is TCP connection data.3. The routing method as described in claim 2 wherein the TCP connectiondata is aggregated over a given time period.
 4. The routing method asdescribed in claim 3 wherein the TCP connection data is aggregated withconnection data from each of the edge servers co-located in the CDNregion over the given time period.
 5. The routing method as described inclaim 1 wherein the step of using the data comprises: determiningwhether a given quality of service is being obtained by routingrequesting clients to the CDN region; and if the given quality ofservice is not being obtained, generating the new routing decision tobias requesting clients away from the CDN region.
 6. The routing methdas described in claim 1 wherein the step of using the data comprises: iffirst and second CDN regions are best able to service a given clientrequest, generating the new routing decision to bias the given clientrequest to the CDN region with data associated with a higher quality ofservice.
 7. The routing method as described in claim 1 wherein the datais collected on a per connection basis.
 8. The routing method asdescribed in claim 7 wherein the data is collected on a per HTTPconnection basis.
 9. The routing method as described in claim 1 whereinthe data is collected for a configurable percentage of client requeststo the given edge server.
 10. A routing method operative in a contentdelivery network having a request routing mechanism for routing clientsto edge servers, comprising: at edge servers located within a CDNregion, collecting TCP connection data statistics as connections areestablished between requesting clients and the CDN region and requestsare serviced by the edge servers; providing the TCP connection datastatistics from the edge servers to the request routing mechanism; atthe request routing mechanism, using the TCP connection data statisticsto determine whether a given quality of service is being obtained byrouting requesting clients to the CDN region; and if the given qualityof service is not being obtained, directing requesting clients away fromthe CDN region.
 11. The routing method as described in claim lo whereinthe requesting clients are directed away from the CDN region until theTCP connection data statistics indicate that the given quality ofservice is being obtained.
 12. The routing method as described in claimlo wherein the TCP connection data statistics are collected on a perconnection basis.
 13. The routing method as described in claim 12wherein the TCP connection data statistics are collected on a per HTTPconnection basis.
 14. The routing method as described in claim lowherein the TCP connection data is collected for a configurablepercentage of client requests to a given edge server.
 15. A methodoperative in a content delivery network request routing mechanism thatgenerates maps for use in directing client requests to subsets of CDNservers, comprising: receiving TCP connection data statistics from oneor more subsets of CDN servers; and using the TCP connection datastatistics in generating a client-to-CDN server mapping.
 16. The methodas described in claim 15 wherein the TCP connection data statistics aregenerated on a per connection basis.
 17. The method as described inclaim 16 wherein the TCP connection data statistics are generated on aper HTTP connection basis.
 18. The method as described in claim 15wherein the TCP connection data statistics are collected for aconfigurable percentage of client requests to a given edge server in asubset of CDN servers.
 19. In a content delivery network request routingmechanism that generates maps for use in directing client requests tosubsets of CDN servers, the improvement comprising: code for receivingTCP connection data statistics from one or more subsets of CDN servers;and code for using the TCP connection data statistics in generating aclient-to-CDN server mapping.